RESTful Webサービスの認証保護

RESTful API はステートレスであり、セッションやクッキーは使用すべきではありません。このため。Webアプリケーションとは異なり、ユーザの認証ステータスをセッションやクッキーで保持することが出来ないため、全てのリクエストに何らかの認証情報を付加する必要があります。

RESTful Webサービスにセキュリティ、認証、承認を処理する方法はたくさんあります。

多くのフレームワークで、それらは手間がかかり複雑で面倒な手続きが必要になり、

場合によっては、コード全体の50％以上になる可能性もあります。

セキュリティー仕様には次のようなものがあります。

認証と承認はユーザ名とパスワードで行われ、"ユーザ名:パスワード" をBase64でエンコードした文字列をアクセス・トークンとして送信します。ユーザ名やパスワードのログイン情報が常に開示されるためセキュリティが脆弱となります。

認証と承認を処理するいくつかの方法を定義する仕様です。

通常はユーザ名とパスワードで認証を行い承認されたクライアントにはアクセスキーを返します。クライアントはこのアクセスキーをアクセス・トークンとして送信することセキュリティを高めています。

OAuth2は非常に広範な仕様であり、他にもいくつかの複雑な使用例をカバーしています。

これには、Facebook や Google, Twitter など外部の認証を用いる方法も含まれています。

OAuth2は通信の暗号化方法を規定していません。アプリケーションはHTTPSで提供されることを想定しています。

OAuth2 とは異なり、通信を暗号化する方法の仕様が含まれているため、複雑な認証です。

この理由で人気がなく現在はほとんど使用されていません。

OpenID Connect

OpenID Connectは、OAuth2に基づく別の仕様です。

相互運用性を高めるために、OAuth2を拡張してあいまいさが提供されます。

たとえば、GoogleログインはOAuth2 に基づいたOpenID Connectを使用しますが、

FacebookログインはOpenID Connectをサポートせずに、独自に実装したOAuth2を使用しています。

OpenID

OpenID Connect と間違いやすいのですが、OpenID仕様もあります。

OpenID はOpenID Connectと同じように相互運用性を高めることを解決しようとしています。

ただしOAuth2に基づいてはいないため追加仕様となっていることから、

人気がなく現在はほとんど使用されていません。

OpenAPI

以前はSwaggerとして知られていた OpenAPI は、OAuth2を含むさまざまなセキュリティー・スキームをサポートしています。現在はLinux Foundation で管理されているAPIを構築するためのオープンな仕様です。